The translateValidationError fallback return message; passes unfiltered Rust/ObjC error strings directly to handleChromeImportError, which places them in a toast message.

These strings originate deep in the native layer — for example anyhow!("Failed to call ObjC command: {}", e) and anyhow!("Failed to parse ObjC response: {}", e) in sandbox.rs. They may contain:

• Full filesystem paths (e.g., the resolved bookmark path surfaced on a bookmark-resolution failure)
• Internal Rust/ObjC type names or stack context
• Content derived from a browser's Local State JSON file, which is attacker-influenced data — a crafted browser installation could place arbitrary strings in that file that bubble up through JSON parse errors

This violates P05 (Controlled Access to Vault Data) — vault-adjacent operation context leaks to the UI — and constitutes Data Leaking per Bitwarden's security vocabulary. It also breaks the Trusted Channel model for output authenticity: the user cannot distinguish a genuine Bitwarden error from a string injected via a crafted browser data directory.

CWE-209 (Generation of Error Message Containing Sensitive Information).

Fix. Remove the raw fallback. All unrecognized messages should map to the generic "errorOccurred" i18n key. The existing string-equality check for "browserAccessDenied" is also fragile — prefer matching all known sentinel keys up-front and catching everything else with the generic key.

startAccessingBrowser: calls [url startAccessingSecurityScopedResource] on a resolved NSURL instance and returns its .path string. The NSURL itself is not retained anywhere.

stopAccessingBrowser: (called later from Drop) resolves the bookmark data a second time via URLByResolvingBookmarkData: to get a new NSURL instance, and calls stopAccessingSecurityScopedResource on that new instance.

Apple's documentation explicitly states: "You must call this method on the same URL object on which you called startAccessingSecurityScopedResource." Calling stop on a different NSURL instance — even one resolved from the same bookmark data — does not decrement the correct scope counter. The result is that the security scope opened in startAccessingBrowser: is never balanced: the sandboxed process retains read access to the browser directory indefinitely (until process exit) rather than only for the duration of the import operation.

This violates P05 (Controlled Access to Vault Data) — the app retains filesystem access beyond the user's intended grant window — and undermines P06 (Minimized Impact of Security Breaches) because the extended open scope increases the window during which a compromised renderer could initiate additional reads.

CWE-772 (Missing Release of Resource after Effective Lifetime).

Fix. Retain the NSURL from startAccessingBrowser: in an NSMutableDictionary keyed by browserName (similar to how bookmarks are stored), and call stopAccessingSecurityScopedResource on that retained instance in stopAccessingBrowser:.

ScopedBrowserAccess::Drop spawns an async task via tokio::task::spawn without storing the JoinHandle. If:

• The Tokio runtime has already begun shutdown when Drop fires (e.g., the import completes and the process tears down),
• The task is dropped before it executes, or
• tokio::task::spawn panics because no runtime is active on the current thread (e.g., a synchronous test path),

then the stop_access ObjC command never executes. Combined with the NSURL symmetry bug above, this creates two compounding failure paths where the security scope is never released.

Even in the non-shutdown case, fire-and-forget spawning means there is no observable signal if the stop silently fails, making the access leak undetectable at the application layer.

This violates P05 (Controlled Access to Vault Data): access to the browser directory (which contains plaintext saved passwords and browsing history — Vault-adjacent data) remains open beyond the user's authorized operation.

CWE-772 (Missing Release of Resource after Effective Lifetime).

Fix. Use a synchronous IPC path for the stop operation in Drop, or redesign ScopedBrowserAccess as an async-only type with an explicit async fn close(self) that is .awaited at the call site, removing the Drop impl entirely. At minimum, gate the spawn on tokio::runtime::Handle::try_current() so a missing runtime is a no-op rather than a panic.

The IPC handler for chromium_importer.getMetadata accepts isMas: boolean from the renderer process and forwards it directly to native code:

ipcMain.handle("chromium_importer.getMetadata", async (event, isMas: boolean) => {
  return await chromium_importer.getMetadata(isMas);
});

All other new handlers (requestBrowserAccess, getAvailableProfiles, importLogins) correctly use the authoritative isMacAppStore() check in the main process and ignore any renderer-supplied value. getMetadata is the only handler that defers to the renderer.

When mas_build=true is passed, DefaultInstalledBrowserRetriever::get_installed_browsers returns all supported browsers without probing the filesystem. A compromised renderer can call getMetadata(true) on a non-MAS build to enumerate all supported browser names without any filesystem-presence check — bypassing the gate that normally prevents disclosure of which browser configurations Bitwarden supports on the user's machine.

This is a trust boundary violation at the IPC layer: the renderer is an untrusted context (runs in a sandboxed renderer process) and should not control security-relevant flags. This implicates P05 (Controlled Access to Vault Data) and TC (Trusted Channel) — the IPC channel is not authenticating the legitimacy of the renderer-supplied flag.

CWE-20 (Improper Input Validation) / CWE-610 (Externally Controlled Reference to a Resource).

Fix. Replace the renderer-supplied parameter with the authoritative main-process value, identical to the pattern used for the other three handlers:

ipcMain.handle("chromium_importer.getMetadata", async (_event) => {
  return await chromium_importer.getMetadata(isMacAppStore());
});

Drop isMas from apps/desktop/src/app/tools/preload.ts and desktop-import-metadata.service.ts accordingly.

BROWSER_BUNDLE_IDS in sandbox.rs lists the same 7 browsers — Chrome, Chromium, Microsoft Edge, Brave, Arc, Opera, Vivaldi — that are already enumerated in SUPPORTED_BROWSERS in apps/desktop/desktop_native/chromium_importer/src/chromium/platform/macos.rs. There is no compile-time enforcement keeping them in sync.

The is_browser_installed function silently falls back to return Ok(true) when a browser name has no corresponding bundle ID entry (let Some(bundle_id) = bundle_id else { return Ok(true); }). This means a browser added to SUPPORTED_BROWSERS in macos.rs without a matching entry in BROWSER_BUNDLE_IDS will bypass the installation check entirely and show up in the UI as installed on MAS builds.

Fix. Add an optional bundle_id: Option<&'static str> field to BrowserConfig and derive the bundle-ID lookup from that field rather than maintaining a parallel list. Alternatively, replace the silent Ok(true) fallback with Ok(false) (or an Err) so the parity gap fails loudly.

ImportDesktopComponent._onLoadProfilesFromBrowser (desktop component) and ImportChromeComponent.translateValidationError (shared importer library) both contain the same pattern-matching logic for the chromiumImporterBrowserNotInstalled:... error key and the browserAccessDenied string.

Because _onLoadProfilesFromBrowser runs first and re-throws with an already-translated human-readable string, the matching code in translateValidationError is dead for errors originating from the desktop profile-loading path. If the error-key format ever changes, both locations must be updated in sync — with no compile-time guarantee they stay consistent.

Fix. The error encoding/decoding contract should live in one place. Either both layers pass structured error codes (not translated strings) up the chain, or the translation happens exclusively at the outermost catch boundary. Mixing translated strings with error-code patterns makes the flow hard to follow and easy to break silently.

getMetadata accepts isMas from renderer; other handlers derive it in main process

apps/desktop/src/main/tools/import/chromium-importer.service.ts:7
Caught by: Architecture agent
Original severity: ♻️ Refactor
Original confidence: 92/100
Dismissed at: Step 5 severity audit
Dismissed because: Duplicate of sec-4 — same underlying issue (getMetadata trusting renderer-supplied isMas), weaker framing.

chromiumImporterBrowserNotInstalled error-string parsing duplicated across two components

apps/desktop/src/app/tools/import/import-desktop.component.ts:60-86
Caught by: Architecture agent
Original severity: ♻️ Refactor
Original confidence: 85/100
Dismissed at: Step 5 severity audit
Dismissed because: Duplicate of quality-3 — same underlying issue (error-string parsing duplicated across components), weaker framing.

tokio::task::spawn in Drop panics if no runtime is active at drop time

apps/desktop/desktop_native/chromium_importer/src/chromium/platform/sandbox.rs:146-164
Caught by: Code quality agent
Original severity: ⚠️ Important
Original confidence: 85/100
Dismissed at: Step 5 severity audit
Dismissed because: Duplicate of sec-3 — same underlying issue (tokio::task::spawn in Drop panics if no runtime), weaker framing.

stopAccessingBrowser resolves a new NSURL instance instead of reusing the one from startAccessingBrowser

apps/desktop/desktop_native/objc/src/native/chromium_importer/browser_access_manager.m:156-175
Caught by: Code quality agent
Original severity: ⚠️ Important
Original confidence: 82/100
Dismissed at: Step 5 severity audit
Dismissed because: Duplicate of sec-2 — same underlying issue (NSURL start/stop symmetry), weaker framing.

Raw system error messages displayed to users as toast content

libs/importer/src/components/chrome/import-chrome.component.ts:193-195
Caught by: Bug analysis agent
Original severity: ⚠️ Important
Original confidence: 85/100
Dismissed at: Step 5 severity audit
Dismissed because: Duplicate of sec-1 — same underlying issue (raw error fallback reaching user-facing toast), weaker framing.

BROWSER_BUNDLE_IDS (sandbox.rs lines 7-15) duplicates the browser-name keys already enumerated in SUPPORTED_BROWSERS (apps/desktop/desktop_native/chromium_importer/src/chromium/platform/macos.rs lines 14-43) and KEYCHAIN_CONFIG (macos.rs lines 68-104). Adding or removing a Chromium-based browser now requires synchronized edits across three parallel arrays in two files, with the only coupling being a string compare on the name field. The new sandbox path looks the bundle ID up by name; the natural home for that data is on BrowserConfig itself (e.g. an optional bundle_id: Option<&'static str> field next to data_dir) so the macOS browser table remains the single source of truth.

Within a single class, two different patterns are used for the same mas_build parameter that is threaded all the way through napi → Rust:

• chromium_importer.getMetadata accepts isMas from the renderer (apps/desktop/src/app/tools/import/desktop-import-metadata.service.ts calls this.system.environment.isMacAppStore() and ships it across IPC; preload.ts forwards it).
• chromium_importer.requestBrowserAccess, getAvailableProfiles, and importLogins ignore any renderer hint and derive the value in the main process by calling isMacAppStore() from apps/desktop/src/utils.ts.

Pick one. The main-process isMacAppStore() utility is already used by every other consumer in apps/desktop/src/main/ and is the established pattern for this signal. Threading the boolean through preload and the renderer for getMetadata only adds a parameter to the IPC contract that the main process does not trust for the other three handlers — and the preload-side change in apps/desktop/src/app/tools/preload.ts only updated getMetadata and requestBrowserAccess to accept new args, leaving the other two preload signatures unchanged, which makes the asymmetry visible in three layers.

translateValidationError (in libs/importer) calls i18nService.t("chromiumImporterBrowserNotInstalled", ...) and i18nService.t("browserAccessDenied"). Both keys are added only to apps/desktop/src/locales/en/messages.json in this PR — they don't exist in libs/common or apps/web/apps/browser locales.

This violates the apps/libs boundary documented in the repo's CLAUDE.md ("Strict boundaries must be maintained between apps and libraries"). Today the shared component is wired only by the desktop callback so the codepath isn't reached in web/browser, but a sibling app that wires onLoadProfilesFromBrowser will silently render the raw key. Move the strings into a shared locale, or move the translation step into the desktop caller and have the shared component pass through already-translated messages.

Three of four IPC handlers (requestBrowserAccess, getAvailableProfiles, importLogins) call isMacAppStore() themselves in the main process and ignore any renderer-supplied flag. getMetadata, however, accepts isMas from the renderer. Pick one. The main-process isMacAppStore() utility is the established pattern for this signal; threading the boolean through preload and the renderer for getMetadata only adds a parameter to the IPC contract that the main process does not trust for the other three handlers. (Same root issue as the architecture agent's finding above; surfaced here from the renderer-side perspective.)

Drop calls tokio::task::spawn to send a stop_access cleanup. Two concerns:

1. tokio::task::spawn panics if no current runtime is available. In the Drop path that becomes a double-unwind and aborts the process. The construction sites today are all async fn resume() calls, so the runtime is reliably present when the value is constructed and dropped — but a future refactor that constructs/drops ScopedBrowserAccess synchronously (e.g., for testing) would silently introduce abort-in-Drop.
2. The returned JoinHandle is discarded and the result of desktop_objc::run_command is ignored (let _ = ...). Cleanup is fire-and-forget; if the runtime tears down before the task runs, the security-scoped resource is not released until process exit.

Recommend an explicit async fn close(self) consumed by import_logins before returning, with Drop retained only as a best-effort fallback gated by tokio::runtime::Handle::try_current() so it cannot panic.

#[derive(Debug, Deserialize)]
struct RequestAccessResponse {
    #[allow(dead_code)]
    bookmark: String,
}

The field is parsed from the ObjC response but never read — the only consumer matches CommandResult::Success { .. } with ... The #[allow(dead_code)] annotation papers over a true unused field added by this PR rather than removing it. Either delete the field (the ObjC side already saves the bookmark to NSUserDefaults, so there's no need to round-trip it across FFI) or have a consumer actually read it.

Same Drop + tokio::task::spawn concern as flagged by the code quality and security agents. The bug-analysis perspective: the JoinHandle is discarded and let _ = desktop_objc::run_command(input_json).await swallows any error, so any failure to release the security-scoped resource is invisible. In practice the runtime is always present when the value is dropped (because the construction site is async), so this lands at refactor severity rather than important. See the quality-3 finding above for the suggested fix.

The napi .d.ts declares requestBrowserAccess(browser: string, masBuild: boolean): Promise<void> with masBuild required. The preload bridge sends only browser:

requestBrowserAccess: (browser: string): Promise<void> =>
  ipcRenderer.invoke("chromium_importer.requestBrowserAccess", browser),

The ipcMain handler in chromium-importer.service.ts calls chromium_importer.requestBrowserAccess(browser, isMacAppStore()), so functionally this works today. However, the inconsistent shape — getMetadata forwards isMas from the renderer, requestBrowserAccess/getAvailableProfiles/importLogins do not — is the same root issue surfaced by the architecture agent. A future change that wires requestBrowserAccess to honor a renderer-supplied flag will silently break.

The only mechanism intended to release the security scope at the end of an import is Drop → tokio::task::spawn → stop_access. The result is discarded (let _ = ...), so any failure to release the scope is silent. The doc comment in import_logins ("releases the scope on Drop after the reads complete") advertises a contract that is not reliably honored.

The runtime presence guarantee at the construction site means this does not cross the Important bar in practice — but the cleanup pattern is the kind of P05 (Controlled access) concern worth tightening: an explicit awaited close() with the panic-prone Drop reduced to a guarded fallback would make the contract observable.

Strict path-equality check returns generic error on mis-selection

apps/desktop/desktop_native/objc/src/native/chromium_importer/browser_access_manager.m:65-71
Caught by: Code quality agent
Original severity: ⚠️ Important
Original confidence: 82/100
Dismissed at: Step 4 validation
Dismissed because: UX nit, not a bug — the Local-State JSON validation provides defense-in-depth and the dialog pre-selects the expected directoryURL, so the common path passes the equality check; users selecting a different path getting a generic error is a UX polish item below Refactor severity.

Trailing whitespace and out-of-order entry in messages.json

apps/desktop/src/locales/en/messages.json:4806
Caught by: Code quality agent
Original severity: ♻️ Refactor
Original confidence: 80/100
Dismissed at: Step 4 validation
Dismissed because: Trailing whitespace in JSON is harmless and a linter would catch it; the out-of-order placement of the new key is sub-Refactor noise that a senior reviewer would not block on.

is_browser_installed returns true for unknown browser names

apps/desktop/desktop_native/chromium_importer/src/chromium/platform/sandbox.rs:197
Caught by: Bug analysis agent
Original severity: ⚠️ Important
Original confidence: 90/100
Dismissed at: Step 4 validation
Dismissed because: The only caller request_only validates browser_name against SUPPORTED_BROWSERS before invoking is_browser_installed, and BROWSER_BUNDLE_IDS contains the same seven entries as macOS SUPPORTED_BROWSERS, so the unknown-name branch is unreachable today; the structural drift risk is already covered by arch-1.

stopAccessingBrowser resolves bookmark to a fresh NSURL — start/stop unbalanced

apps/desktop/desktop_native/objc/src/native/chromium_importer/browser_access_manager.m:154
Caught by: Bug analysis agent
Original severity: ⚠️ Important
Original confidence: 85/100
Dismissed at: Step 4 validation
Dismissed because: Apple's documented contract for security-scoped resources balances start/stop calls on the URL but does not unambiguously require the same NSURL instance — the underlying counter is on the resolved security scope, and per the validation directive without conclusive proof of an instance-identity requirement this is dismissed.

stopAccessingBrowser calls stop on different NSURL instance — scoped resource not released

apps/desktop/desktop_native/objc/src/native/chromium_importer/browser_access_manager.m:153
Caught by: Security & logic agent
Original severity: ⚠️ Important
Original confidence: 85/100
Dismissed at: Step 4 validation
Dismissed because: Same reasoning as the bug-analysis duplicate above — cannot conclusively confirm Apple's contract requires the identical NSURL instance for stopAccessingSecurityScopedResource; the security-scope counter is associated with the resolved bookmark scope, not strictly the Obj-C object identity.